โ RNS 1.4.2 released https://pypi.org/project/rns/
๐ฌค rns.recipes
top
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ Communicating with serial interface โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Started by Necom ยท 1mo ago ยท 15c9a46c70d24d73
Page 1 of 2
[ 1 ] Next >
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-1
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Necom #1 โ
โ 15c9a46c70d24d73 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 1mo ago
This computer doesnโt have an IP connection so the only way I can connect to a reticulum
network is via LoRa, which makes it a bit annoying to do things that require sending
larger amounts of data, like updating reticulum, since I would have to change the LoRa
settings to prioritise speed rather than range whenever I need to do something like that.
Ever since I got the Heltec V4s my old V3s have been laying and collecting dust. So I
figured, they have wi-fi radios, I like to code and since my brother got me that book
about C last year Iโve learnt some of the basics of it so why not take this opportunity
to learn how to write firmware for ESP32s and repurpose my V3s. I managed to get them to
transmit and receive packets over wi-fi, so now I need to make them communicate with
reticulum so they can actually be used as an 802.11 interface. I would write an interface
driver but I donโt really know how to do that, I think I remember reading that that would
require some kind of class, and Iโm not entirely certain what a class even is (well in
the context of programming at least) so that seems like a daunting task. Then thereโs the
pipe interface, but that still requires me to figure out how to communicate over serial,
and I donโt really feel like doing that right now. Maybe Iโll do it eventually, if I have
to.
For now I figured, the serial interface can already communicate over serial, and as far
as I know it just uses a specific byte to separate packets from each other, and then
somehow avoids that byte appearing in packets and being confused for a packet delimiter
(I donโt know how exactly, just that it does it).
So theoretically, all I need to do is store each byte being received over serial in an
array, and when the packet delimiter (0x7E) is received I simply transmit the packet that
is in the array, and then I clear the array, so itโs ready for more packets. And when I
receive a packet over wi-fi I simply send it over serial followed by 0x7E. All Iโm really
doing is stripping the packet delimiter from the packet and transmitting it, then adding
the delimiter back in at the other end, so the other reticulum instance should receive
the exact same packet that the first one sent. And from what I can tell that seems to be
exactly what is happening. I plug my Heltec into my computer and look at the serial
monitor in the Arduino ide and I can see the path requests and announces coming through,
followed by 0x7E.
And yet for some reason when I try to get 2 reticulum instances to communicate like this,
they both report receiving 0 bytes on the serial interfaces. So does anyone know if there
is some flaw in trying to communicate with the serial interface this way or if I just
implemented it badly and the packets actually are being changed somehow?
โ 0 โ 1 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-2
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Necom #2 โ
โ 15c9a46c70d24d73 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 21d ago
I got a serial monitor program called tio that can output the exact bytes received on the
usb port, from the esp32. The following is a path request for this forum:
7e 08 00 6b 9f 66 01 4d 98 53 fa ab 22 0f ba 47 d0 27 61 00 9c e9 28 08 be 49 8e 9e 05 59
0f f2 7c bf df e4 61 61 20 d6 52 bc 56 d5 7f 78 a8 6b 36 40 65 93 7e
As it seems the packet was successfully received over wifi and sent over serial Iโm
wondering, is this packet somehow invalid or is reticulum not receiving the packets
coming in on the port? Could the interface be misconfigured? This is how the interface is
currently configured:
[[ESP32 802.11 Interface]]
type = SerialInterface
enabled = yes
port = /dev/ttyUSB0
mode = gateway
Should an interface configured like this ignore that packet or is this some kind of bug
or?
โ 0 โ 0 โค 1
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-3
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Necom #3 โ
โ 15c9a46c70d24d73 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 20d ago
Update: It seems to work with the following configuration:
[[Serial Interface]]
type = SerialInterface
enabled = yes
port = /dev/ttyUSB0
speed = 115200
databits = 8
parity = none
stopbits = 1
The packet loss is pretty high though. I measured it with โrnprobe -v -n 512โ and it
reported a packet loss of 53.71%, with most packets having a round trip return time of 80
- 200ms, and I think I remember seeing a packet with a time of 500ms once or twice. After
further testing it seems most of the packets from my MacBook do reach the raspberry pi,
but a lot of packets travelling in the opposite direction, from the raspberry pi to the
MacBook, are lost. I tried switching the esp32s, so the MacBook was using the esp32 that
the raspberry pi had been using, and vice versa, to see if it would affect this partial
unidirectionality somewhat. It did not, most packets from the raspberry pi were still
lost, and most packets from the MacBook werenโt. I have no idea what could be causing all
this packet loss and partial unidirectionality, so not sure Iโm going to be able to do
anything about it. Hopefully someone else here might have some idea
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-4
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Necom #4 โ
โ 15c9a46c70d24d73 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 8d ago
Finally I found and fixed the bug causing the packet loss, just had to add a couple
parenthesis in the code. "rnprobe -v -n 1024" now shows only 2 packets lost, and most
packets have a round trip return time of 100 - 200ms, some are a little under 100ms. The
speed varies a little, sometimes it's 1 - 10Kbps, but sometimes it's like 10 - 20Kbps.
It's certainly faster than I was able to get with LoRa, and now I don't have to change
the LoRa setting to prioritise speed whenever I want to update reticulum. I updated it
less than an hour ago, completely over wi-fi
โ 2 โ 0 โค 2
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-5
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Mark #5 โ
โ bc7291552be7a58f โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 8d ago
That's awesome. Thanks for sharing your learning and experiments, that was intereseting
to read. For someone who's pretty much starting out in programming and just got a book
about C, I'd say what you've achieved here is a job pretty well done! Props to you man.
Keep learning, keep experimenting and keep building stuff :)
โ 0 โ 0 โค 1
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-6
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Mark #6 โ
โ bc7291552be7a58f โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 8d ago
And also, keep pushing the limits :) You can achieve very high reliability and good
effective speeds using the ESP32 WiFi chipset. Here's a small demo of what the devices
are capable of.
Here, the ESP32-S3 chipset is running my custom 802.11 Weave protocol, running the WiFi
transceiver in the long-range PHY mode, at a raw on-air rate of 500 Kbps, 20 MHz channel
width. This provides cryptographic multi-hop switching and automatic peer discovery over
the switched fabric.
Effective throughput is 300+ Kbps for the actual Reticulum traffic with bi-directional
communication over several kilometers.
$ rnstatus
WeaveInterface[Weave Test]
Status : Up
Mode : Gateway
PHY Rate : 500.00 kbps
CPU load : 3 %
Mem usage : 0.41 %
Switch ID : 17:bb:1f:95
Endpoint : ad:ae:40:8e:d7:3e:75:14
Peers : 1 reachable
Traffic : โ19.82 KB 2.20 Kbps
โ2.34 MB 301.12 Kbps
Also very good reliability and low packet loss:
$ rnprobe rnstransport.probe db2a9002c9fe24af54169df531d52bf2 -n100
Sent probe 1 (16 bytes) to <db2a9002c9fe24af54169df531d52bf2>
Valid reply from <db2a9002c9fe24af54169df531d52bf2>
Round-trip time is 118.849 milliseconds over 5 hops
[ ... ]
Sent probe 99 (16 bytes) to <db2a9002c9fe24af54169df531d52bf2>
Valid reply from <db2a9002c9fe24af54169df531d52bf2>
Round-trip time is 443.529 milliseconds over 5 hops
Sent probe 100 (16 bytes) to <db2a9002c9fe24af54169df531d52bf2>
Valid reply from <db2a9002c9fe24af54169df531d52bf2>
Round-trip time is 440.827 milliseconds over 5 hops
Sent 100, received 100, packet loss 0.0%
โ 1 โ 0 โค 3
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-7
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Necom #7 โ
โ 15c9a46c70d24d73 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 8d ago
Thanks! That means a lot coming from you. I have been very excited about Weave and Iโll
definitely use it for the speed increase, but since I have no idea when Itโll be out Iโll
just have to stick with my own firmware for now. Do you have any idea when it might be
out?
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-8
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Mark #8 โ
โ bc7291552be7a58f โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 8d ago
> since I have no idea when Itโll be out
Lol, me neither :) It works quite well, but all the user-facing tooling and management
systems are non-existent currently, so it's practically impossible to use unless you know
how to send the correct config packets manually ;)
And having your own firmware is also a bit more satisfying in a way, isn't it?
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-9
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Mark #9 โ
โ bc7291552be7a58f โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 8d ago
And if you keep messing around with it, you can get the same kinds of speeds as well, or
even faster :)
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-10
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Necom #10 โ
โ 15c9a46c70d24d73 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 8d ago
> And having your own firmware is also a bit more satisfying in a way, isn't it?
Indeed, it is!
> And if you keep messing around with it, you can get the same kinds of speeds as well,
or even faster :)
Sounds exciting, will definitely try!
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
[ 1 ] Next >
Page 1 of 2
โ INFO โ Identify to this node to post. How?
bottom